Many electronic devices contain embedded counters that can be used to monitor state and/or performance of the containing device. The value of such a counter is typically retrieved by a software application at discrete points in time, with the difference between the resulting values (sometimes referred to as the “delta”) being used to determine the rate at which an occurrence being reported by the counter is happening on, to, or around the device. These deltas and/or derived rates can subsequently be used for various purposes, typically to assess the health or efficiency of the device.
Such embedded counters are usually presented to a retrieving software application as unsigned hexadecimal values. An application that retrieves and interprets such counters must therefore be capable of correctly handling various conditions that may apply to each individual counter, such as the rollover of the counter's value from a large unsigned number to a small unsigned number due to a small number of counted occurrences. The proper treatment of counters is well understood and fairly common within certain types of software applications (e.g. network management applications).
It is the norm that software applications deal with each such counter of interest from a device by treating each one directly and distinctly from others, in terms of managing the counter value and computing deltas and rates. While it is atypical for retrieving software applications to combine the values of individual embedded counters, such aggregation can be quite useful when it is desired to combine and abstract the resulting counter deltas away from the specifics of the embedded counters that supplied them. One might wish to do this when using the aggregated counters to assess device behavior that encompasses a relatively broad criterion that is not represented by any single embedded counter within the device. For example, it might be desired to consider the total number of errors seen by a device rather than the more detailed counters that are typically provided to break out each possible type of error. This abstraction approach can also be used to “normalize” the statistics that are collected from disparate device types or models that fall within a common device class.
Almost all prior solutions tackle the situation of divergent embedded counters among supported device types or models by essentially avoiding entanglement in this area, which unfortunately limits their ability to perform analysis on the aggregated deltas. That is, it is atypical for most applications that deal with such embedded device counters to abstract and/or combine the counter deltas before performing analysis and/or presentation of the deltas. Normally the delta from each individual counter that a device type or model keeps is presented distinctly from all others to the user of a software application, with the burden of reconciling counter sets from divergent device types or models and the interpreting the resultant deltas falling upon the user. It is appreciated that this becomes quite difficult for the users of such applications when the supported device types or models become increasingly divergent from one another, as a common means of assessing device behavior and performance is quite difficult to derive if even possible at all.
One prior solution attempts to aggregate the raw, unsigned values that are retrieved from a device and then compute deltas using the resulting total. This minimizes the burden on a network management application as it does little but retrieve the appropriate values from each supported device type or model. Unfortunately this approach can yield incorrect results when more than one of the embedded counters being combined experiences a rollover at the same time; it becomes impossible to tell which counters rolled over and by how much, and even how many counters rolled over.
The most common prior solution simply requires the software application that is consuming the embedded counter values to be capable of dealing directly with disparate counter sets from various specific device types or models. This typically results in special casing and/or logic being scattered throughout the application to handle the quirks associated with each supported device type or model. It also limits the type of analysis and interpretation of the counter deltas and rates that the application itself is able to perform, as the counter sets are usually of divergent composition between device types or models.